Introducción a las pruebas
public int suma(int a, int b)
{
return a + b;
}
¿Qué casos de prueba podemos escribir?.
Y algunas permutaciones más.
En conclusión
Probar es ejecutar casos de prueba.
Caso de prueba:
entrada + acciones + salida
salida obtenida == salida esperada
salida obtenida != salida esperada
¿Un programa que pasa todos sus casos de prueba es un programa sin errores?.
En conclusión
No
Las pruebas sólo pueden encontrar los errores que buscan.
Por esto es tan importante un buen diseño de pruebas.
SubNiveles de prueba
FASES DE LA PRUEBA
Diseño de las pruebas (¿técnicas?)
Generación de casos de prueba (¿datos de prueba?)
Definición del procedimiento de la prueba (¿cómo, donde?)
Ejecución de la prueba
Informe de la prueba (¿resultados?)
TÉCNICAS DE PRUEBA
Pruebas estructurales o de Caja Blanca.
Pruebas funcionales o de caja negra.
ESTRATEGIAS DE PRUEBA
Pruebas unitarias.
Pruebas de integración.
Pruebas de sistema.
Pruebas de aceptación.
Pruebas de regresión.
Niveles de prueba
Aspectos que trataremos hoy
Niveles de prueba
Pruebas unitarias
Cuando: Durante la construcción del sistema.
Objetivo: Prueban el diseño y el comportamiento de cada uno de los componentes una vez construidos.
Pruebas unitarias
Técnicas:
Análisis de caminos.
Partición de categorías.
Mutaciones.
Algoritmos genéricos.
En general, han sido muy estudiadas.
Pruebas de integración
Herramientas:
Las mismas, vamos sustituyendo los mocks por las clases reales y, si es necesario, escribiendo más casos de prueba.
Cuando: Durante la construcción del sistema
Objetivo: Comprueban la correcta unión de los componentes entre sí a través de sus interfaces, y si cumplen con la funcionalidad establecida
Pruebas de integración
Técnicas:
Arriba abajo:
El primer componente que se prueba es el primero
de la jerarquía (A). Una de las ventajas es que las
interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.
Abajo a arriba:
Se prueban primero los componentes de más bajo
nivel (E, F) Este tipo de enfoque permite un
desarrollo más en paralelo, pero presenta mayores
dificultades a la hora de planificar y de gestionar.
Pruebas de sistema
Herramientas:
Cuando: Durante la construcción del sistema (partes completas).
Objetivo: Prueban a fondo el sistema, comprobando su funcionalidad e integridad globalmente, en un entorno lo más parecido posible al entorno final de producción.
Herramientas:
Técnicas: probar el sistema como lo hará el usuario final.
Pruebas de implantación
Herramientas:
Cuando: Durante la implantación en el entrono de producción.
.
Objetivo: Comprueban el correcto funcionamiento del sistema dentro del entorno real de producción (rendimiento, copias de seguridad, etc.).
Herramientas:
Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas.
Pruebas de aceptación
Herramientas:
Cuando: Después de la implantación en el entorno de producción.
Objetivo: Verifican que el sistema cumple con todos los requisitos indicados y permite que los usuarios del sistema den el visto bueno definitivo.
Herramientas:
Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas.
Pruebas de regresión
Cuando: Durante el mantenimiento del sistema.
Objetivo: Comprobar que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados
Herramientas:
Las mismas.
Características de una buena prueba
Ha de tener una alta probabilidad de encontrar un fallo. Cuanto más, mejor.
No debe ser redundante. Si ya funciona, no lo probamos más.
Debe ser la "mejor de la cosecha". Si tenemos donde elegir, elegimos la mejor.
No debería ser ni demasiado sencilla ni demasiado compleja. Si es muy sencilla no aporta nada, si es muy compleja a lo mejor no sabemos lo que ha fallado.
SubAutomatización de las pruebas
Automatización de las pruebas
"No sirven para nada"
"Engaño"
"Pérdida de tiempo"
"Descartadas al primer cambio"
"Imposibles de mantener"
"Moda"
¿Por qué?.
Algunas palabras que hemos escuchado hablando de pruebas.
Automatización de las pruebas
Las pruebas son polémicas:
No son parte de la solución.
No se las entregamos a nuestros clientes.
Incluso pueden darles a nuestros clientes una mala impresión.
Nuestros clientes no nos las pagan.
Difíciles de mantener.
Sin embargo, las pruebas son imprescindibles.
La automatización nos permite reducir costes.
Automatización de las pruebas
¿Qué significa automatizar?.
¿Qué podemos automatizar?.
En este caso concreto: realizar de manera automática mediante herramientas software.
Diseño de las pruebas
Codificación de las pruebas
Ejecución de las pruebas
Evaluación de resultados
Lo más habitual, muchas técnicas y herramientas
Menos habitual, pocas técnicas y herramientas.
El objetivo de esta presentación
Automatización de las pruebas
Ventajas de la automatización:
Mayor rapidez de ejecución.
Menos recursos.
Evitamos pruebas obsoletas
Automatización de las pruebas
Inconvenientes:
¡Muy pocas herramientas!.
Necesitan una "base" a menudo inexistente.
Un conjunto pobre de pruebas.
Automatización de las pruebas
Cuando automatizar y cuando no automatizar.
Bien
Mal.
Gastamos más en la automatización que en la pruebas en sí.
No buscamos automatizarlo absolutamente todo.
Tenemos modelos y documentación del sistema.
Construimos el sistema sobre la marcha.
Nosotros controlamos las herramientas de prueba.
Las herramientas de prueba nos controlan a nosotros.
 Página anterior | Volver al principio del trabajo | Página siguiente  |